Мы уже писали о некоторых особенностях лицензирования VMware vSphere 5, где основным нововведением является ограничение по количеству памяти, используемой виртуальными машинами. Кроме того, мы также писали об особенностях лицензии на бесплатный VMware ESXi 5. А сегодня мы поговорим еще об одном типе лицензии VMware vSphere 5 - vSphere Desktop.
VMware vSphere Desktop - это специальное издание VMware vSphere 5, которое позиционируется как платформа для виртуализации настольных ПК предприятия (Virtual Desktop Infrastructure). Ранее лицензию для виртуальных ПК можно было приобрести, купив решение VMware View, включающее в себя брокер соединений и ПО для виртуализации приложений VMware ThinApp.
Но теперь, поскольку новая схема лицензирования хост-серверов с ограничением по памяти оказалась весьма дорогой для VDI, компания VMware вынуждена была ввести лицензию на платформу виртуализации для виртуальных ПК без необходимости приобретать брокер соединений от VMware.
Итак, что же такое vSphere Desktop:
Это полностью функциональная платформа, обладающая возможностями VMware vSphere Enterprise Plus (то есть максимум возможностей). При этом нет никаких ограничений по количеству используемых хост-серверов, процессоров и ядер, хранилищам, оперативной памяти ВМ (vRAM) и вообще технических ограничений нет почти никаких (хотя возможно останется ограничение по числу vCPU для ВМ).
А принцип приобретения прост - вы покупаете лицензию на 100 включенных одновременно виртуальных машин (под которые можно использовать сколько угодно серверов ESXi 5), которая стоит $6 500 (само собой, это в америке - у нас будет как всегда дороже).
Кроме того, vSphere Desktop - это та лицензия, которая поставляется вместе с VMware View в качестве платформы для ПК.
Ниже показан пример сравнения стоимости лицензий для 1000 виртуальных ПК, если их приобретать по обычной схеме (vSphere Enterprise Plus по процессорам) и по лицензии vSphere Desktop. В строчках - разные разное количество памяти виртуальных машин на процессор хоста, по сути - коэффициент консолидации.
Как видно из расчетов - лицензия vSphere Desktop получается выгоднее. Хотя тут VMware, конечно, кривит душой - не всем нужен Enterprise Plus для того, чтобы поддерживать виртуальные ПК.
Второй важный момент лицензирования vSphere Desktop, помимо цены - это возможность использовать сторонние брокеры соединений на базе платформы vSphere 5. В первую очередь, речь идет о Citrix XenDesktop, который очень большое количество пользователей применяет именно на базе vSphere. Теперь им станет полегче.
Несколько важных моментов лицензии vSphere Desktop:
Эту лицензию можно только купить, в нее нельзя сконвертировать текущие лицензии vSphere.
Если вы используете виртуальные ПК на обычном издании vSphere - на здоровье, главное, чтобы за ограничение по памяти не вылезать.
Лицензии можно приобретать только комплектом по 100 виртуальных ПК. Это минимальный шаг.
Один и тот же vCenter можно использовать для виртуальных серверов vSphere и виртуальных десктопов vSphere Desktop. Для каждого издания ограничения по памяти считаются отдельно, поэтому на ограничения обычной vSphere на виртуальные ПК не повлияют.
Параллельно с релизом новой версии платформы виртуализации VMware vSphere 5 компания VMware объявила о выходе новых версий еще нескольких продуктов своей линейки для организации частных облаков. Один из них - VMware Site Recovery Manager 5, где появилось несколько полезных новых возможностей и улучшений.
Взглянем на общую картину улучшений:
Как мы видим, основных моментов, отличающих VMware SRM 5 от предыдущей версии, три - это репликация на уровне хостов VMware ESXi 5, возможность запланированных миграций и автоматизированный failback (восстановление на основную площадку с резервной после восстановления работы первой).
Рассмотрим сначала репликацию на уровне хоста (Host Based Replication):
Теперь нам предлагается 2 вида репликации в VMware Site Recovery Manager 5. Наиболее критичные виртуальные машины (Tier 1 apps) мы защищаем с помощью репликации на уровне дисковых массивов (а значит, это дорого), а менее критичные (Tier 2) мы защищаем с помощью Host Based Replication. Под менее критичными приложениями мы подразумеваем такие, у которых требования к точке восстановления составляют от 15 минут до 24 часов (именно для таких и применяется репликация).
Взглянем на репликацию в VMware Site Recovery Manager 5 поближе:
На каждом хосте VMware ESXi 5 у нас работает vSphere Replication Agent (VSR Agent), который передает все данные об изменении виртуальных дисков машин на резервный сайт в асинхронном режиме с некоторым интервалом. Наличие агента означает, что репликация на базе хоста будет работать только, начиная с VMware ESXi 5.
На резервном сайте работает vSphere Replication Server, который собирает данные об изменениях виртуальных дисков с основной площадки и применяет их к виртуальным машинам на хранилищах резервного сайта. Также на обеих площадках есть компонент vSphere Replication Management Server, который тесно интегрирован с vCenter и SRM и необходим для управления процессом репликации, а также чтобы управлять несколькими vSphere Replication Server, потому как какждый из них обслуживает около 100 машин.
Рассмотрим теперь новый рабочий процесс - Planned Migrations:
Теперь, помимо основного процесса DR Failover, в VMware SRM 5 есть процесс Planned migration (он входит в Recovery Plan). Он позволяет выключить виртуальные машины, синхронизировать хранилища и переместить виртуальные машины на резервную площадку. Поскольку машины выключаются корректно, они переезжают на резервную площадку без вреда для приложений и данных.
Данный процесс может быть полезен для обслуживания основного сайта, тестирования возможности восстановления и просто для переезда виртуальных машин на резервную площадку по необходимости. Ну и, по-сути, на практике его можно применять, когда команда основной площадки знает, что через некоторое время основной сайт будет выведен из строя и есть возможность машины на некоторое время остановить для миграции.
Ну и третье наиболее значимое нововведение VMware Site Recovery Manager 5 - Automated Failback:
Это та возможность, которую так долго ждали пользователи VMware SRM. Теперь в продукте есть механизм реализации двунаправленных миграций за счет автоматизации операций по переключению с резерва на основной сайт (Failback).
При инициации Failback, VMware SRM 5 взаимодействует с массивом, чтобы повернуть репликацию в обратную сторону, а затем выполняет Recovery Plan в обратном направлении в отношении основного сайта (то есть отдельный план восстановления для Failback не нужен).
Для данной возможности SRM 5 есть два ограничения:
основной сайт не должен измениться после восстановления (то есть там нельзя снова переустановить хосты ESXi)
эта функция не работает с vSphere Host Based Replication
Лицензирование VMware Site Recovery Manager 5
Ну и рассмотрим, что изменилось в лицензировании VMware Site Recovery Manager 5. У нас есть теперь два издания SRM - Standard и Enterprise, оба с одинаковым функционалом:
Как видно из таблицы, единственная разница - это то, что в издании SRM Standard есть ограничение на 75 виртуальных машин на одной площадке. Здесь отчетливо видно, что цена в $195 за виртуальную машину для издания Standard (а значит, и для среднего и малого бизнеса) - это попытка конкурировать с продуктом Veeam Backup and Replication 5, который еще со своей первой версии умеет делать репликацию виртуальных машин между площадками. Однако здесь совершенно понятно, что даже при 7 виртуальных машинах на двухпроцессорный хост (а это немного) - VMware SRM уже проигрывает по цене Veeam Backup and Replication (а в последнем есть помимо репликации еще много чего).
Маппинг лицензий существующих пользователей VMware Site Recovery Manager на пятую версию будет проходить так:
Обновление на VMware SRM 5 для пользователей с активной подпиской и поддержкой (SnS) происходит бесплатно. Все получают издание SRM Enterprise, однако есть нюанс: те, кто покупал SRM по процессорам хостов ESX / ESXi теперь получают лицензии по количеству виртуальных машин из расчета 5 лицензий на ВМ для одной купленной ранее лицензии на процессор (невыгодно, да, а что делать). Это потому, что VMware SRM уже достаточно давно лицензируется только по количеству защищаемых виртуальных машин.
Вот вкратце и все. Если у вас будет интерес к тому, чтобы мы подетальнее описали VMware Site Recovery Manager 5 - то сделаем технический обзор.
Мы уже писали о новых возможностях версии Citrix XenServer 6.0 "Project Boston", теперь же он доступна для свободного скачивания с сайта Citrix, при этом добавилось несколько новых функций.
Чуть более развернутое описание новых возможностей Citrix XenServer 6.0:
Product Simplification - Технологии Workload Balancing, StorageLink и Site Recovery полностью интегрированы в XenServer. Управление ими происходит через центральную консоль XenCenter, все виртуальные модули (virtual appliances) теперь построены на базе Linux и поставляются в соответствующих форматах VA (например, модуль Workload Balancing). Дистрибутив теперь поставляется на одном CD.
Architectural Changes - в качестве гипервизора используется доработанный Xen 4.1, включающий в себя распределенный коммутатор Open vSwitch (OVS), который используется по умолчанию. В Open vSwitch появились улучшения NIC Bonding (Teaming), поддержка Jumbo Frames. Говорится также об улучшении производительности сетевого взаимодействия до 70-100% для некоторых сценариев. Также есть поддержка SR-OIV и увеличена производительность сетевого взаимодействия (особенно для продуктов NetScaler VPX и SDX).
Self-Service & Cloud Building Tools - новая консоль Self-Service Manager позволит создавать окружения с сервисом самообслуживания пользователей (поставляется в виде виртуального модуля с веб-интерфейсом). Это что-то вроде облачного менеджера для частных облаков, который поддерживает платформы XenSever и VMware vSphere. Поддерживаются виртуальные модули OVF, возможность создавать многомашинные конфигурации (vApp) для использования с функциями HA и Site Recovery, а также возможность импорта виртуальных дисков VMware VMDK и Microsoft VHD.
Microsoft System Center Integration - Управление хостами XenServer и виртуальными машинами из System Center Virtual Machine Manager (VMM) 2012. Также предполагается мониторинг XenServer с помощью System Center Operations Manager 2012, на который будет накатываться специальными пакет от Citrix (подробности будут позже).
XenDesktop Enhancement & Improvements - Улучшения технологии HDX для оптимизации производительности виртуальных ПК и поддержка GPU Pass-Thru, что позволяет раздавать ресурсы видеоадаптера виртуальным машинам (поддержка как single GPU card, так и multi-card GPU card). Это все позволяет за счет технологии XenDesktop HDX 3D Pro улучшить поддержу CAD и требовательных к графике приложений.
Guest OS Support Updates - поддержка гостевых ОС Ubuntu 10.04, RHEL 5.6 и SLES 10 SP4. Экспериментальная поддержка Solaris и Ubuntu 10.10. Версии RHEL 6 и Debian Squeeze поддерживаются еще с XenServer 5.6 SP2.
Platform Enhancements & Improvements - мастер "Rolling Pool Upgrade" (упрощение миграции с 5.6 на 6.0), поддержка хранилищ NFS для высокой доступности (HA) и последовательности загрузки ВМ в случае сбоя, поддержка 1ТБ памяти хост-сервера, улучшенные параметры количества vCPU (16) и vRAM (128 ГБ) для виртуальных машин, улучшения NIC bonding (а также поддержка active/passive bonding).
Другие изменения - Self-Service Manager - это замена Lab Manager. Поддержка последнего еще некоторое время останется. Некоторые массивы перестали поддерживаться StorageLink, что проверяется при апгрейде с 5.6 на 6.0. Кроме того, теперь Site Recovery не зависит от технологии StorageLink, что позволяет более гибко подходить к созданию катастрофоустойчивых конфигураций на базе XenServer.
Мы уже писали о некоторых расширенных настройках дисковой подсистемы серверов VMware ESX / ESXi, которые позволяют управлять доступом виртуальных машин к хранилищам VMFS. Сегодня постараемся описать еще несколько параметров:
Опишем еще несколько параметров Advanced Settings для категории Disk:
Disk.MaxLUN - это число (по умолчанию 256, т.е. ID от 0 до 255), опеделяющее максимальное количество томов, доступных серверу VMware ESX / ESXi.
Disk.MaskLUNs = "vmhba1:0:32-35;vmhba2:0:1,5,7-9" - это параметр, определяющий маскирование томов VMFS в SAN. В данном примере от хоста ESX / ESXi скрываются LUN с ID от 32 до 35 для HBA-адаптера vmhba1, а также LUN с ID 1,5,7,8,9 для адаптера vmhba2. Разделитель для адаптеров - точка с запятой.
Disk.SupportSparseLUN - эта настройка включена по умолчанию (значение 1), по желанию ее можно выставить в 0. Значение 1 означает, что на ESX / ESXi включена поддержка номеров LUN, идущих непоследовательно (например, 0,6 и 23). Если у вас все LUN идут по порядку, то можно отключить эту функцию, выставив значение 0. В этом случае будет тратиться немного меньше времени на сканирование всех LUN.
Disk.DiskMaxIOSize - с помощью этого параметра можно задать максимальный размер операции ввода-вывода (IO request). По умолчанию, сервер VMware ESX / ESXi поддерживает объем IO-запроса размером до 32767 KB, запросы большего объема разбиваются на части. Для некоторых хранилищ (это надо смотреть в документации) такой размер IO-запроса, генерируемый некоторыми приложениями может оказаться слишком большим и привести к снижению производительности. Поэтому можно уменьшить этот параметр, в зависимости от модели дискового массива. Более подробно описано в KB 1003469.
Disk.SchedQControlVMSwitches - по умолчанию, этот параметр равен 6. Он означает вот что. Когда у нас несколько виртуальных машин отдают свои IO к LUN, у нас вступает в игру параметр Disk.SchedNumReqOutstanding (а не глубина очереди адаптера), который определяет границу для виртуальных машин по одновременной отдаче команд ввода-вывода. Если эта граница превышена - наступает постановка команд в очередь. Но VMkernel должен перед этим обнаружить, что LUN использует несколько ВМ. Так вот Disk.SchedQControlVMSwitches определяет сколько раз должен VMkernel это обнаружить. А понимает он это только тогда, когда следующее IO приходит не от той машины, которая дала предыдущий IO. Надо понимать, что это значение может быть достигнуто не очень скоро, когда у нас есть одна высоконагруженная ВМ A на одном LUN, и там же есть низконагруженная по IO машина (B). И это хорошо, поскольку в таких окружениях не должно быть урезания по вводу-выводу для высоконагруженной ВМ.
Disk.SchedQuantum - по умолчанию, этот параметр равен 8. Он определяет число высокоприоритетных последовательных команд, которые идут к дисковому устройству. Последовательными командами считаются те, которые идут к расположенным рядом секторам диска. Что такое расположенные рядом сектора диска? Это те, которые (по умолчанию) находятся друг от друга на расстоянии не более 2000 секторов. Такие команды выполняются до 10 раз быстрее, чем с далекими секторами.
Disk.SectorMaxDiff - это и есть параметр, определяющий, что такое "близкие" секторы для предыдущего параметра. По умолчанию, он равен 2000.
Disk.SchedQControlSeqReqs - этот параметр (по умолчанию, 128) определяет число последовательных IO без переключений (т.е. последовательность команд только от одной ВМ), после которых счетчик Disk.SchedQControlVMSwitches будет сброшен в 0, а машина сможет использовать опять всю очередь адаптера. Этот параметр нужен для того, чтобы после всплеска нагрузки на ВМ B в первом примере, когда этот всплеск прекратится, ВМ A снова смогла получить в свое распоряжение всю очередь адаптера и дальше работать в интенсивном режиме без входа в игру параметра Disk.SchedNumReqOutstanding, который распределяет IO на LUN.
Воткнули? Нет? Тогда еще раз перечитывайте статью Duncan'а. А еще один блоггер, Andy Grant, нарисовал замечательную картинку (кликабельно):
Как знают пользователи VMware vSphere, в версии платформы 4.1 появилась новая возможность по управлению приоритетами ввода-вывода виртуальных машин для хранилищ на уровне кластера под названием Storage IO Control (SIOC). Но эта функциональность доступна только в издании vSphere Enterprise Plus, что оставляет множество пользователей за бортом.
В рамках одного хост-сервера VMware ESX / ESXi есть механизм по управлению приоритетами ВМ для хранилищ с помощью Disk Shares (в настройках ВМ). Однако эти приоритеты могут быть заданы только в относительных значениях, что тоже в некоторых случаях неудобно.
В версии VMware vSphere 4.1 появилась возможность задать параметры ограничения ввода-вывода для конкретных ВМ с помощью абсолютных значений (в числе операций в секунду - IOPS и в пропускной способности в секунду - MBps). Это может пригодиться для отдельных виртуальных машин, для которых есть риск "забивания" канала к системе хранения.
Как можно эти параметры добавлять:
Нажмите Edit Settings для выключенной виртуальной машины.
Перейдите на вкладку Options.
В категории Advanced: General нажмите кнопку Configuration Parameters.
Нажмите Add Row.
Далее можно добавить 2 параметра (обратите внимание, что они задаются для каждого виртуального диска):
sched.<diskname>.throughputCap = <value><unit>
Например:
sched.scsi0:0.throughputCap = 10KIOps
sched.<diskname>.bandwidthCap = <value><unit>
Например:
sched.scsi0:0.bandwidthCap = 10KBps
В качестве значений можно использовать буквы K (KBps или KIOps), M (MBps или MIOps) и G (GBps или GIOps). Подробнее в KB 1038241.
По наблюдениям автора, если задать оба параметра для виртуального диска, они будут проигнорированы хост-сервером. А если для каждого диска одной ВМ задать определенные лимиты, то для каждого из этих дисков лимит установится как сумма для двух (то есть, если мы поставим 100IOps и 50IOps, лимит для каждого диска станет 150IOps).
Напоминаю, что работает это только, начиная с VMware vSphere 4.1 (и для ESX, и для ESXi).
Случилось так, что один из билдов новой операционной системы Windows 8 утек в сеть (build 7989). Блоггер Robert McLaws, заведующий веб-ресурсом windows-now.com, нашел в новой ОС несколько возможностей, относящихся к виртуализации на базе Hyper-V, вероятно, версии 3.0.
Вот что нашел Роберт:
Хранилища
Виртуальный HBA-адаптер для виртуальных машин - Virtual Fibre Channel Adapter (хотя на картинке не он, а просто новые настройки сети для виртуальных машин).
Пулы ресурсов для систем хранения (картинка), которые позволяют кобинировать различные категории хранилищ в целях лучшей управляемости.
Новый формат виртуальных дисков VHDX, который поддерживает диски до 16 ТБ, а также имеет возможности защиты от сбоя питания (картинка). Данный формат может быть использован, только начиная с Windows 8.
Улучшения вычислительных ресурсов (Memory/Processor)
Поддержка более 4 ядер (картинка, я не очень понял что имеется в виду).
Новые настройки NUMA-узлов (картинка - Memory per Node, Cores per Node, Nodes per Processor Socket).
Улучшения сетевого взаимодействия (Networking Enhancements)
Поддержка аппаратного ускорения для сетевых адаптеров (картинка - техники Virtual Machine Queue и IPsec Offload).
Управление пропускной способностью адаптеров (картинка - минимум, максимум).
DHCP Guard - запрет на получение адресов неавторизованным виртуальным машинам.
Router Guard - отклоняет сообщения Advertisement и Redirection для неавторизованных ВМ, которые хотят притвориться роутерами.
Monitor Port - возможность перенаправления трафика виртуальной машины (входящего и исходящего) на другой порт в целях мониторинга ИБ.
На конференции Citrix Synergy компания Citrix объявила о приобретении Kaviza (напомним, что в прошлом году Citrix сделала стратегические инвестиции в Kaviza). Это вендор, который выпускает решение VDI-in-a-box. Это такой виртуальный модуль (Virtual Appliance), который позволяет упростить процедуру внедрения VDI в небольших компаниях.
Kaviza VDI-in-a-box не требует брокеров соединений, серверов управления и балансировщиков нагрузки - все умещается в одном виртуальном модуле. Получаем вот такую картинку "до и после":
При этом решение VDI-in-a-box не требует общего хранилища для виртуальных ПК - можно использовать локальные диски серверов. Это и быстрее (локальные диски vs общее хранилище), и не требует дополнительных инвестиций в создание инфраструктуры СХД.
В продукте даже есть некий High Availability Grid Engine, который обеспечивает отказоустойчивость для виртуальных ПК на хост-серверах.
Кстати, ранее в качестве платформы поддерживались VMware vSphere, Citrix XenServer и Microsoft Hyper-V. Теперь же непонятно, оставит ли Citrix поддержку VMware, хотя логичных причин прекращать ее нет.
Также отметим, что Kaviza имеет в своем составе поддержку Linked Clones для виртуальных ПК, а в качестве протокола доступа с клиентских устройств использует RDP либо Citrix HDX.
В целом, VDI-in-a-box - штука весьма интересная и SMB-пользователи должны повнимательнее к ней присмотреться. Тем более, что под крылом Citrix продукт, будем надеяться, станет лучше.
Реселлеры смогут начать поставки VDI-in-a-box по каналам Citrix уже с 1 июля этого года. Скачать пробную версию ПО Kaviza можно по этой ссылке.
Таги: Citrix, Kaviza, VDI, SMB, VMachines, HDX, HA
Мы уже писали про компанию 5nine и ее продукты. Она делает различные утилиты для управления виртуальной инфраструктурой серверов Hyper-V. Теперь вышел еще один (и опять бесплатный) продукт - 5nine Hyper-V Manager.
Утилита занимает интересную нишу: Hyper-V Manager может быть установлен локально на сервере Hyper-V (поддерживаются установки Windows Server 2008 R2 в версиях Full и Core, а также бесплатный Hyper-V Server 2008 R2). С этого же сервера администратор и может производить управление виртуальными машинами через GUI (поддерживается и удаленное управление).
То есть, для управления небольшой виртуальной инфраструктурой вам не нужен ни System Center VMM, ни Remote Server Administration Tools for Windows 7.
Основные возможности 5nine Hyper-V Manager:
Hyper-V Management – продукт позволяет управлять виртуальными машинами, виртуальными дисками и сетевым взаимодействием. Можно управлять хостами Hyper-V R2 в домене.
Network Management – 5nine Manager for Hyper-V позволяет управлять виртуальными сетями и привязками адаптеров. Очень удобная штука, так как при выходе сети из строя не всегда есть возможность управлять хост-сервером удаленно.
Secure your Hyper-V Hosts – типа не требуется ничего дополнительно навешивать на хост-сервер.
Simple and Easy to Use – привычный для пользователей Windows интерфейс. GUI для Windows 2008 R2 Core.
Maximize Host Performance - утилита потребляет мало ресурсов.
Какие операции поддерживаются в 5nine Hyper-V Manager:
Добавление, удаление и редактирование свойств ВМ, сетей и виртуальных дисков.
Просмотр выделенных ресурсов и производительности
Управление снапшотами
Управление службами Hyper-V
GUI для импорта и экспорта сетевых шар на Windows Core и бесплатном Hyper-V Server
Скачать 5nine Hyper-V Manager можно по этой ссылке.
Слышали про такую проблему VDI Boot Storm? Вот у вас есть инсталляция системы виртуализации корпоративных ПК предприятия (например, на базе VMware View 4.x) на несколько десятков или даже сотен пользователей виртуальных ПК. В 8:00 у вас начинается рабочий день - пользователи приходят за свои рабочие места и одновременно включают свои виртуальные десктопы. В результате возникает серьезная нагрузка на систему хранения, где эти самые образы виртуальных ПК хранятся (десятки, сотни машин на сторадже).
И получается вот такой VDI Boot Storm - машины тормозят, сессии отваливаются, пользователи жалуются. Ведь при загрузке Windows 7 генерирует где-то 50-100 IOPS, а при обычной офисной работе это значение составляет 5-15 IOPS. Наглядно это выглядит так:
Что же делать с этим VDI boot storm?
Ну, во-первых, вы должны это обязательно учитывать при планировании развертывания инфраструктуры виртуальных ПК. Ваша инфраструктура хранения FC или iSCSI должна учитывать такие пиковые нагрузки, и начало рабочего дня - отличный способ это проверить. Есть также вот инструмент VDI Sizing Tool (VST) от нашего соотечественника, который позволяет мерить нагрузку для VDI-сценариев.
Во-вторых, SSD-диски. Да, дорого. Но иногда без них нельзя. Если вы используете VMware View с функциональностью View Composer для создания связанных клонов виртуальных ПК на основе базового образа - вам поможет концепция ярусного хранения данных, реализованная в продукте. На быстрые SSD-накопители можно помещать реплики пулов виртуальных ПК и Disposable-диски виртуальных машин. Сравните 150-200 IOPS у SAS-дисков с 5000 у SSD.
В-третьих, есть специализированные решения, такие как, например, NSS SAN Accelerator for VMware View. Эта штука представляет собой железку с SSD-дисками, которая ставится между хост-серверами VMware ESX / ESXi и системой хранения. Она умеет автоматически кэшировать наиболее часто используемые блоки и выравнивать нагрузку по хост-серверам.
В четвертых, есть мысль, что перед тем, как пользователь пришел на работу, его виртуальный ПК уже должен быть готов к работе и запущен. Мысль самая разумная, но почему-то нормальная настройка этого механизма в VMware View отсутствует. Вроде как даже из интерфейса View 4.5 убрали шедулинг запуска виртуальных ПК. А какого-то централизованного механизма вроде нет. Или есть? Может вы подскажете?
Kenny Coleman, один из блоггеров, пишущий о виртуализации VMware, выпустил пакет утилит для администраторов виртуальной инфраструктуры vSphere / ESX под названием VM Advanced ISO. Пакет содержит в себе набор необходимых программ для рутинных задач с виртуальными машинами:
Утилиты 1 - P2V Clean-up
01 - Resolution Resize (меняем разрешение гостевой ОС)
02 - HP ProLiant Cleaner (вычищаем софт HP после миграции в ВМ)
Бывает такое, что при резервном копировании виртуальной машине VMware vSphere на томе NFS (не VMFS!) виртуальная машина перестает отвечать на пинги, консоль подвисает и с ней не соединиться по RDP.
Такие вещи случаются, когда вы используете Veeam Backup and Replication 5 в режиме Changed Block Tracking (CBT), то есть с отслеживанием изменившихся блоков для более быстрого резервного копирования. Связано это с особенностями работы NFS-лочек, которые могут "провисать" до 30 секунд, в течении которых машина и зависает.
Если это вас так сильно беспокоит, Changed Block Tracking можно просто отключить в настройках задачи резервного копирования Veeam Backup and Replication:
Но если отключите CBT - бэкапы будут делаться медленнее. Так что выбирайте.
О чем нам рассказывает данный документ в плане безопасности платформы VMware vSphere 4.1:
Защита хост-серверов виртуализации VMware ESX / ESXi 4.1
Безопасность виртуальной машины как контейнера для гостевой ОС (то есть не рассматривается защита ОС в виртуальной машине и приложений)
Правильная конфигурация виртуальной инфраструктуры в целом: средства управления, сети хранения данных, виртуальные коммутаторы (но не сеть между ВМ)
Защита VMware vCenter Server, его базы данных, а также vSphere Client
Защита сервера VMware Update Manager (как главного средства своевременного наката обновлений, в том числе в плане безопасности)
Есть полезные рекомендации, а есть весьма пространные. Очень удобно, что они разбиты на блоки, в пределах которого разъясняется суть угрозы, пример воздействия на инфраструктуру и область применения (Enterprise, DMZ и Specialized Security Limited Functionality (SSLF)). Вот пример полезной рекомендации:
Напоминаем также, что в настоящее время идет публичное обсуждение данного руководства для продукта VMware View - VMware View Security Hardening.
P.S. Не забываем про скрипт VMware vSphere Security Hardening Report Check, который позволяет проверить вашу виртуальную инфраструктуру на соответствие VMware vSphere 4.x Security Hardening Guide.
Мы уже писали о ставших официально известными подробностях о новой версии платформы виртуализации VMware vSphere 5.0. С мной поделились интересной ссылкой на подробное описание новых функций vSphere 5.0, которое сделано, судя по всему, на базе Release Candidate версии продукта.
Поскольку я не нахожусь под действием NDA и не участвую в бета-программе, я могу поделиться с вами основными ключевыми возможностями vSphere 5.0 (приведены лишь ключевые особенности - остальные по ссылке выше):
1. Платформа vSphere 5.0 будет построена только на базе гипервизора ESXi - без возможности установки ESX. Сервер управления VMware vCenter 5.0 будет поддерживать управление хостами ESXi 5.0, ESX/ESXi 4.x и ESX/ESXi 3.5.
2. VMware vSphere Auto Deploy - полная поддержка автоматизированного развертывания хостов ESXi.
3. Новые возможности виртуальных машин - 32 виртуальных процессора (vCPU), 1 TB RAM, 3D-акселерация для поддержки Windows Aero, UEFI virtual BIOS, поддержка устройств USB 3.0 (пока только для Linux-систем и только для проброса через vSphere Web Client - напрямую к хосту нельзя). Устройства USB 2.0 теперь поддерживаются к пробросу в виртуальные машины через vSphere Client или vSphere Web Client.
6. Dynamic Resource Scheduling (DRS) for Storage - эта давно ожидаемая функция платформы виртуализации, которая позволит автоматически выравнивать нагрузку на системы хранения путем динамического перемещения работающих виртуальных машин между хранилищами (сейчас это можно сделать вручную за счет Storage VMotion). Пользователи смогут определять группы Datastor'ов (они зовутся Storage Pods), которые будут использоваться для балансировки по хранилищам на базе их заполненности. Предполагается, что это повысит автоматизацию датацентров. Вроде как присутствует и генерация рекомендаций по балансировке и Initial Placement на базе параметров IO.
7. Policy-driven storage delivery - политики размещения виртуальных машин на хранилищах на базе правил, задаваемых администратором. Это позволит регулировать качество обслуживания систем со стороны хранилищ и автоматически определять наилучшее место хранения виртуальных машин.
8. Файловая система VMFS 5.0.
9. Accelerator - новая технология кэширования данных виртуальных ПК для VMware View, увеличивающая их производительность.
10. Полный контроль за iSCSI адаптерами (программными и аппаратными) из графического интерфейса.
12. Swap to SSD - для хранилищ администратор будет назначать тэги, наиболее производительные хранилища SSD будет рекомендовано использовать для хранения swap-файлов в целях ускорения быстродействия.
13. Поддержка LUN для VMFS томов размером более 2 ТБ.
14. Поддержка технологии Storage vMotion для виртуальных машин со снапшотами.
15. Enhanced Network I/O Control (на уровне виртуальных машин) - эта возможность будет позволять резервировать часть канала для приоритетных задач в кластере HA/DRS на случай его перегрузки. Актуально это будет для сетей 10G, где канал шире, а вот физических адаптеров значительно меньше.
16. ESXi Firewal - новый сетевой экран с фильтрами по диапазонам IP для каждой службы.
17. vSphere Web Client на базе технологии Adobe Flex с большим спектром возможностей. Старый vSphere Client под Windows также останется.
18. vCenter Server Appliance - виртуальный модуль на базе Linux с предустановленной службой vCenter. О CTP-версии данного продукта мы уже писали.
19. Enhanced logging support - поддержка логирования на удаленные серверы, в том числе на несколько серверов от одного источника по безопасному каналу SSL. Для vSphere Client будет плагин vSphere syslog listener, который позволит настраивать данную функциональность.
20. Fault Domain Manager - специализированный модуль управления высокой доступностью VMware HA, который еще больше увеличивает уровень доступности виртуальных машин. Кроме того, теперь все хост-серверы VMware ESXi в кластере являются первичными узлами (primary nodes) - то есть кластер HA переживет любое число отказов.
21. Host-based replication for Site Recovery Manager - возможность репликации виртуальных машин на уровне хостов а не SAN-хранилищ (как делается сейчас). То есть, поддержка технологии репликации со стороны СХД будет не нужна, репликация будет работать в асинхронном режиме со стороны хост-серверов. По-сути, это аналог репликации виртуальных машин в продукте Veeam Backup and Replication 5, которая сейчас активно используется в производственной среде многими компаниями для защиты данных виртуальных машин и наиболее быстрого восстановления работоспособности сервисов (показатели RTO).
Выход VMware vSphere 5.0 запланирован на второе полугодие 2011 года. Но скорее всего пятая версия платформы выйдет до VMworld 2011, который начнется 29 августа.
Естественно, информация неофициальная и список новых возможностей VMware vSphere 5.0 может быть изменен в любой момент. Но вот что будет точно - так это отсутствие гипервизора ESX - так что всем организациям пора задуматься о плане перехода на "тонкую" платформу ESXi 5.0.
Если вы вносите изменения в настройки виртуальной машины в файле vmx (что аналогично внесению изменений в Configuration Parameters), например, для ограничения максимального числа снапшотов:
то иногда бывает полезным перезагрузить vmx-файл виртуальной машины без удаления и повторного ее добавления в Inventory vSphere Client. Для этого нужно в консоли выполнить команду:
Механизм VMware High Availability (HA) в VMware vSphere позволяет автоматически перезапустить виртуальные машины отказавшего сервера в кластере с общего хранилища в случае сбоя. При настройке кластера VMware HA можно использовать несколько расширенных настроек (HA Advanced Settings), которые позволяют настроить его работу наиболее гибко.
Таги: VMware, HA, ESX, ESXi, Bugs, vSphere, VI, VMachines, Обучение
После выпуска черновой версии VMware vSphere 4.1 Security Hardening, содержащей в себе рекомендации по обеспечению безопасности серверной виртуальной инфраструктуры, компания VMware выпустила черновик очередного документа по безопасности VMware View Security Hardening, в котором приведены лучшие практики для инфраструктуры виртуальных ПК.
Основные разделы:
Лучшие практики по использованию продукта vShield Endpoint (об этом мы писали тут и тут)
Безопасность серверов
VMware View Connection Server и Security Server
Безопасность гостевых ОС – Windows 7
Политики использования PowerShell
Использование клиента View with
Local Mode (как он работает - вот тут)
Работа в режиме
Kiosk Mode (публичный доступ к инфраструктуре виртуальных ПК)
Основные общие практики по сопровождению инфраструктуры View (приложения, сертификаты, сетевая безопасность, роли)
В нем раскрываются технические детали работы антивирусных решений с технологией vShield Endpoint и Security VM (вспомогательная виртуальная машина на хосте ESX, осуществляющая сканирование всех ВМ на нем).
Если речь идет о мониторинге производительности ОС на аппаратной («железной») платформе, то мало у кого возникает вопрос как это делать. Существуют уже давно известные инструменты и способы мониторинга таких систем. Но вот когда речь заходит о мониторинге производительности гипервизора с запущенными на нем виртуальными машинами, тут уже не все так однозначно, а особенно с гипервизором Hyper-V от компании Microsoft. Таги: Microsoft, Hyper-V, Performance, Производительность, VMachines, SCOM
Мы уже писали о семействе продуктов VMware vShield, призванных обеспечивать безопасность виртуальной инфраструктуры на базе VMware vSphere, но многие до сих пор не понимают кому и для чего они нужны. Постараемся вкратце описать их. Massimo Re Ferrè опубликовал хорошую статью по vShield, где нарисовал понятную картинку:
Есть три разных продукта:
vShield Endpoint - это мидлваре (то есть, само по себе для пользователя ничего не делающее ПО), которое построено поверх VMsafe API и позволяет сторонним производителям антивирусов интегрироваться с инфраструктурой виртуализации VMware vSphere. Это, понятное дело, важнее всего для VDI-инсталляций на базе VMware View (поэтому, если у вас нет VDI - продукт вам не нужен). О том, как это работает, и почему это хорошо, мы уже здесь писали. vShield Endpoint идет в комплекте с VMware View Premier.
vShield App - думайте об этом компоненте как о виртуальном распределенном коммутаторе (dvSwitch) с логикой фаервола с неограниченным количеством портов. То есть мы можем контролировать трафик на уровне гипервизора на хостах ESX (опять-таки, работает VMsafe) для различных уровней сетевого взаимодействия. Ну и дальше настраиваем правила, как виртуальные машины будут между собой общаться (порты, протоколы), и все это мониторим. Об этом продукте надо задуматься, когда у вас большая инфраструктура VMware vSphere и повышенные требования к безопасности. Но учтите - продукт этот подходит для внутренней защиты датацентра (т.е. внутренние взаимодействия ВМ).
vShield Edge - это продукт для комплексной защиты периметра датацентра. Это уже более глобальный продукт, он включает в себя такие сервисы как Stateful firewall, VPN, DHCP, NAT, Web Load Balancing и другое. То есть, это такая большая бронированная дверь в ваш виртуальный датацентр, которая обладает возможностями по защите от внешнего мира и контроля взаимодействия с ним. Не всем такое нужно - многие используют свои собственные решения. Но что надо упомянуть, так это то, что vShield Edge интегрирован с продуктом VMware vCloud Director, который предназначен для управления облаками, которые создаются в частных организациях и у сервис-провайдеров. То есть vShiled Edge понимает объекты vCloud Director и защищает их в соответствии с настроенными политиками. То есть, для инсталляций где виртуальная инфраструктра не предоставляется как услуга и где нет внутреннего облака (а, соответственно, и vCloud Director) - продукт Edge особо не нужен.
Теперь еще два важных момента:
Что такое vShield Manager? Это название консоли, которая управляет всеми этими продуктами.
Куда делся vShiled Zones? Никуда он не делся, он так и есть в составе изданий vSphere, начиная с Advanced. Этот продукт является частью vShiled App, а поэтому обладает только некоторыми из его возможностей:
Ну а дальше - читайте статью, там много интересных вещей написано.
Кстати, недавно наши соотечественники из Лаборатории Касперского объявили о поддержке в своих антивирусах продукта vShield Endpoint:
Скачать продукты семейства vShield можно по этой ссылке.
При выборе настольной платформы виртуализации сегодня у пользователей по-сути всего два выбора - VMware Workstation и Oracle VirtualBox. Остальные аналоги настольных продуктов либо уже сняты с производства, либо откровенно не дотягивают до фунционала этих двух платформ.
При этом, VMware Workstation является полноценным коммерческим продуктом с закрытым исходным кодом (исходный код открыт только у VMware Player - урезанной версии Workstation), а Oracle VirtualBox - open source платформа, работающая поверх многих операционных систем (с открытым исходным кодом издание VirtualBox OSE).
Вопросы производительности здесь трогать не будем - их рассматривали ранее тут и тут, но эти обзоры уже неактуальны. В целом, по отзывам пользователей оба продукта показывают более-менее одинаковую производительность в средних условиях (хотя бытует мнение, что VirtualBox быстрее). В данной заметке приведено сравнение VMware Workstation 7.1 и Oracle VirtualBox 4.0.4.
В чем платформы VirtualBox и VMware Workstation обе хороши:
Понятный графический интерфейс
Удобный редактор сетевого взаимодействия на хосте
Диски виртуальных машин, растущие по мере наполнения их данными (Thin Provisioning)
Технология мгновенных снимков (снапшотов)
Технология приложений в хостовой ОС из гостевой ОС в бесшовных окнах (то есть, приложение из виртуальной машины "выносится" в рабочую область хостовой системы, как будто оно в ней и работает)
Поддержка большого количества гостевых ОС, поддержка Windows и Linux в качестве гостевых ОС
Поддержка 64-битных гостевых ОС
Поддержка Intel VT и AMD-V
USB 2.0 устройства в виртуальных машинах
Воспроизведение звука на устройствах хоста из виртуальной машины
Буфер обмена между гостевой и хостовой ОС
Поддержка 3D-графики для игр и других приложений
Поддержка импорта виртуальных модулей (Virtual Appliances) OVF/OVA
Улучшенные драйверы в гостевой ОС: VMware Tools и VirtualBox Guest Additions (оба пакета обновляются автоматически)
Обе платформы поддерживают техники Memory Overcommit (так называемый Memory Ballooning - перераспределение свободной физической памяти между гостевыми ОС виртуальных машин)
Обе платформы поддерживают многопроцессорные виртуальные машины (не менее 8 vCPU)
Расширение виртуальных дисков (в Workstation - удобнее)
Копирование файлов между виртуальной машиной и ОС хоста
Обе платформы имеют поддержку доступа к консоли виртуальной машины через RDP-сервер
Почему можно выбрать VirtualBox, а не VMware Workstation:
VirtualBox абсолютно бесплатен, а VMware Workstaion стоит $207.90 по российскому прайсу на март 2011 г (при покупке менее 10 лицензий).
VMware Workstation работает только в хостовых ОС Windows и Linux, а VirtualBox поддерживает хосты Windows, Linux, Mac OS X и Solaris.
Технология "Teleportation", позволяющая переместить запущенную виртуальную машину на другой хост VirtualBox, без необходимости ее остановки. Данная функция отсутствует в VMware Workstation
VirtualBox имеет возможность работы не только с родным форматом .VDI, но и .VMDK, и .VHD. VMware Workstation имеет возможность исполнять виртуальные машины только из образов виртуальных дисков VMDK (хотя есть бесплатный продукт VMware Converter для импорта виртуальных машин из других форматов).
VirtualBox имеет больше параметров для работы из командной строки (управление ВМ, устройствами, снапшотами и многим другим)
VirtualBox лучше поддерживает аудио для Linux-хостов (Workstation отключает звук в хостовой ОС, VirtualBox может играть параллельно)
VirtualBox имеет возможность ограничения потребления ресурсов CPU и ввода-вывода, у VMware Workstation этого нет (это умеет только VMware vSphere)
VirtualBox имеет возможность регулировки видеопамяти
Почему можно выбрать VMware Workstation, а не VirtualBox:
VMware Workstation - коммерческий продукт, а значит вы всегда сможете рассчитывать на поддержку с определенным уровнем SLA
VMware Workstation имеет больше возможностей для поддержки 3D-графики, как то: Windows Aero user interface, OpenGL 2.1 и Shader Model 3.0. Сама 3D-акселерация работает постабильней, чем в VirtualBox.
VMware Workstation имеет драйвер универсальной печати .ThinPrint (не требуется установка драйверов в гостевую ОС)
Создание снапшотов через заданные интервалы времени (функции AutoProtect), что позволяет защитить виртуальные машины по аналогии с возможностью автосохранения (например, как в Microsoft Word).
Compact Virtual Disks - сжатие виртуальных дисков для отдачи его под нужды других систем.
VMware Workstation имеет более широкий функционал по работе с виртуальным сетевым взаимодействием - коммутаторы, DHCP, NAT и прочее (хотя VirtualBox также имеет NAT, Bridge Networking - в Workstation это субъективно удобнее).
VMware Workstation имеет функционал связанных клонов (Linked Clones) для виртуальных машин.
Запись активности виртуальной машины в видеоформате, а также в виде последовательности действий пользователя (Guest Record / Replay).
Workstation имеет возможности интеграции со средами разработки и тестирования (например, Eclipse), а также специализированные функции для разработчиков ПО (зато у VirtualBox покруче API).
Защита виртуальных машин 256-битным шифрованием
В Workstation несколько приятных мелочей - типа ярлыков на приложения из меню "Пуск", Pause a Virtual Machine (не suspend) и т.п.
В целом, если вы не знаете, зачем конкретно вам нужна именно VMware Workstation, то смело выбирайте бесплатный VirtualBox. Если же вы разработчик ПО или инженер по тестированию - то я рекомендую выбрать VMware Workstation, которая имеет множество удобных мелочей, используемых ежедневно, которые отсутствуют в VirtualBox.
Коллеги, если вы заметили какую-нибудь ошибку в сравнении функционала или у вас есть чем дополнить данное сравнение - напишите, пожалуйста, об этом в комментариях.
Компания VMware на прошлой неделе выпустила продукт VMware vCenter Operations, который позволит системным администраторам и менеджерам датацентров обнаруживать, анализировать и решать проблемы производительности VMware vSphere.
vCenter Operations собирает данные о производительности каждого из объектов виртуальной инфраструктуры VMware vSphere (виртуальные машины, хранилища, кластеры, датацентр в целом), хранит их в централизованной базе данных, анализирует их и делает отчет в реальном времени о текущих проблемах производительности, а также о потенциальных проблемах.
Есть разные представления данных:
Основные особенности vCenter Operations:
Комбинирование ключевых метрик производительности в общее количество баллов для датацентра (CPU, memory, disk, contention performance).
vCenter Operations вычисляет диапазон значений, который находится в рамках допустимой производительности, и подсвечивает отклонения от этого диапазона.
Графическое представление инфраструктуры в контексте производительности с возможностью "проваливания" до отдельных компонентов.
Отображение информации об изменениях в иерархии виртуальной инфраструктуры, после чего vCenter Operations показывает, как эти изменения отразились на производительности различных объектов. Например, если виртуальная машина переместилась за счет vMotion между хостами VMware ESX, vCenter Operations покажет нам как изменилась нагрузка на хост-серверы.
Обзорное видео:
В продукте три основных аспекта представления информации о производительности виртуальной инфраструктуры vSphere:
health - текущее состояние объекта или всего виртуального датацентра. Им назначаются очки, исходя из допустимых значений нормальной производительности, а также на основе исторических данных. Если показатели метрик выходят за данные значения - vCenter Operations оповещает об этом и сообщает о возможных причинах.
analytics - на основе загрузки текущих метрик с помощью данного представления можно определить, какие объекты простаивают (например, хост-серверы), а какие требуют выделения дополнительных ресурсов (например, виртуальная машина).
capacity - показывает какой процент емкости от физических ресурсов занимает тот или иной объект. Далее за счет модуля аналитики можно узнать время, когда ресурсов окажется недостаточно (например, заполнится Datastore) и сделать долгосрочные прогнозы по добавлению новых мощностей в инфраструктуру (вычислительные ресурсы, хранилища).
vCenter Operations поставляется в 3-х изданиях: Standard, Advanced и Enterprise:
Standard
Advanced
Enterprise
Performance Management
Alerting and Visualization
Consolidated Health dashboard
Actionable health scores & KPIs
Top N priority views
Self learning behavior
Dynamic Thresholds
Early warning visualizations
Predictive 'Smart' Alerts
Alert lifecycle mgmt
Custom alerts
Email & SNMP notifications
Analysis & Troubleshooting
1 click root-cause dashboard w/ KPI history
Impact detection (Health trees)
Behavioral performance/workload analysis
Multiple KPI anomaly correlation
Contextual event overlays
HeatMap library
Cross Team views & enablement
Role based access & SSO
Actionable operator views
Problem isolation tools
Report by Custom Groups
vSphere awareness
Multi vCenter support
Integrated into vSphere Client
vSphere Inventory & dependency aware
Support for Reservations & Limits
Capacity Management
Capacity Awareness
Past, present, future capacity summaries
Current capacity bottlenecks
Future capacity shortfall notifications
Alerts on capacity conditions
Schedulable Capacity Reports
Report across multiple vCenters
Capacity Optimization
Analyze & trend resource wastage
Identify over-allocated, idle VMs
Identify under-utilized hosts, clusters
Identify waste from snapshots, templates, orphaned
VMs
Recommendations to reclaim resources
Recommendations to rightsize
Capacity Planning & Forecasting
Estimate remaining capacity
Estimate time remaining to full capacity
Forecast demand & supply
Trend Utilization vs demand
Trend Utilization and allocation
Replenishment recommendations
Interactive What-if modeling
Support for vSphere storage
Support for Peak usage
Support for Business time zones
Cross Team views & enablement
Role based access & SSO
Actionable operator views
Report by Custom Groups
Infra. utilization trend views for Upper mgmt
Supply forecast for provider teams: Storage, Network, Build
Usage & Optimization views for LOB
Cloud capacity reports for Provider & Tenants
Report customization
vSphere awareness
Integrated into vSphere Client
vSphere Inventory & dependency aware
Support for vCloud objects(vDCs)
Support for Thin Provisioning
Support for Reservations & Limits
Support for Linked Clones
Support for HA, FT
Configuration & Compliance Management
Configuration Visibility
Configuration and change visibility
Centralized dashboards
Out of box Reports
Change alerts
Continuous Compliance
Guest Compliance
Host Compliance
vCenter Compliance
Standard Regulatory compliance (SOX, HIPAA, DISA, ISO, BASEL II, PCI DSS, NIST)
Custom policy compliance
Automated compliance violation detection
Compliance remediation recommendations
Compliance remediation automation
Automated Provisioning and Patching
Manage OS distribution centrally
Discover new systems, build/deploy via PXE
Provision ESX/ESXi to "bare metal"
Provision OS to bare metal & VMs
Build and deploy software packages (Windows)
Connect to compliance policies
Automatically detect missing software
Remediate non-compliant systems
Distributed software repository
Cross Team Views & enablement
Role based access control
Active Directory integration
Скачать vCenter Operations с сайта VMware нельзя. Для запроса детальной информации обращайтесь к партнерам компании VMware.
Многие пользователи решения для виртуализации корпоративных ПК предприятия VMware View 4.5 сталкиваются с ситуацией, когда необходимо выполнить определенные действия на виртуальном десктопе в зависимости от того, какое клиентское устройство использует пользователь. Это важно, например, для использования правильного ближайшего принтера (например, у нас есть больница, где врач ходит между кабинетами и может грузиться в свой десктоп), а также монтирования определенных общих сетевых ресурсов (шар).
В VMware View есть OEM-компонент .ThinPrint, отвечающий за универсальную печать в виртуальных ПК. Помимо прочего, он умеет делать так называемый Location Based Printing - то есть монтировать в виртуальный ПК необходимый принтер в зависимости от того, с какого клиента пользователь залогинился в виртуальный ПК. Процедура настройки данного механизма приведена в документе "ThinPrint GPO Configuration for Location-Based Printing".
Правила назначения клиенту принтера могут быть основаны:
IP-адресе клиента
MAC-адресе клиента
Имени пользователя
Членстве пользователя в группах
Имени хоста клиента
Чтобы применить эти правила, вам нужно сначала зарегистрировать библиотеку на VMware View Connection Server. Находится она по следующим путям:
Далее вы увидите новую групповую политику AutoConnect Map Additional Printers for VMware View в Group Policy Editor. Она доступна в ветке Software Settings (сначала создайте новый GPO):
Откройте ее и впишите необходимые параметры политики для печати в зависимости от различных условий (например, MAC-адреса клиента, откуда происходит логин через View Client):
Значения параметров тут достаточно очевидны (например, Client Name - имя хоста, откуда идет доступ с View Client). Здесь важно два момента: укажите точное имя принтера в колонке Printer Name и имя драйвера в колонке Printer Driver (легко ошибиться, берете из виртуального ПК), а также для сетевого принтера не забудьте указать префикс IP_ в колонке IP Port.
Теперь бросьте этот GPO в OU, где у вас лежат ваши виртуальные ПК, к которым вы применяете данную политику печати в зависимости от расположения клиентского устройства. После применения политики, на виртуальном ПК должен появиться ключ реестра:
Можно также делать все эти вещи по-старинке, с помощью скриптов. Хорошее описание того, как с помощью VBS можно смонтировать сетевые шары можно найти у Barry в статье "VMware View and Location Based Scripts". Вот так, например, с помощью VBS можно получить имя клиентской машины, откуда мы заходим в виртуальный ПК:
Option ExplicitDim WshShell, ClientName, objFSO
Set WshShell = WScript.CreateObject(“WScript.Shell”)
Set objFSO = CreateObject(“Scripting.FileSystemObject”)
ClientName = WshShell.RegRead(“HKCU\Volatile Environment\ViewClient_Machine_Name”)
MsgBox ClientName
Ну а в ветке HKCU\Volatile Environment\ лежит вот что:
Все это можно использовать при написании скриптов.
Не так давно на сайте проекта VMware Labs (мы о нем уже писали) появился интересный продукт (а точнее Technical Preview) - VMware vCenter XVP Manager and Converter.
На данный момент этот продукт позволяет привязать к средству управления виртуальной инфраструктурой VMware vCenter хост-серверы и виртуальные машины Microsoft Hyper-V. Не секрет, что многие пользователи (особенно в крупных инфраструктурах) используют виртуализацию VMware vSphere и Microsoft Hyper-V одновременно. Например, это может так: VMware vSphere используется для производственной среды, а Hyper-V для тестовых виртуальных машин и малокритичных задач (как вариант - по соображениям экономии).
Так вот VMware vCenter XVP Manager and Converter позволит перенести часть базовых задач по управлению виртуальной средой Hyper-V на сторону vCenter.
Как это работает. После установки vCenter XVP Manager plug-in for vSphere Client в Inventory клиента появляется вкладка Third-Party Hosts, в которой можно добавить хосты Hyper-V:
На данный момент в текущей версии VMware vCenter XVP Manager and Converter доступны следующие функции по управлению хост-серверами и виртуальными машинами Hyper-V:
Поддержка Microsoft Hyper-V Server 2008, Microsoft Windows Server 2008 (64-bit) с включенной ролью Hyper-V, Microsoft Hyper-V Server 2008 R2, Microsoft Windows Server 2008 R2 с включенной ролью Hyper-V
Стандартный GUI vCenter Server и привычное Inventory
Возможность добавления хостов через System Center Virtual Machine Manager (SC VMM)
Управление питанием виртуальных машин и хостов (перезагрузка, выключение, включение)
Доступ к физической консоли сервера Hyper-V и консоли виртуальных машин
Управление виртуальными устройствами виртуальной машины (память, процессоры, диски и т.п.)
Возможность миграции виртуальных машин Hyper-V на платформу vSphere
Совместимость с VMware vCenter Server 4.0
Возможность управления до 50 хостами Hyper-V
Вот пара видеороликов об установке и простейших операциях с VMware vCenter XVP Manager and Converter:
А вот, что можно делать с виртуальной машиной Hyper-V и ее гостевой системой через vSphere Client:
Кроме того, в VMware vCenter XVP Manager and Converter есть возможность конвертации виртуальной машины Hyper-V на сервер VMware ESX / ESXi. Конвертация происходит путем установки агента внутрь виртуальной машины (то есть, по сути виртуальная машина воспринимается как физическая):
Скачать VMware vCenter XVP Manager and Converter можно по этой ссылке.
Ben Armstrong, занимающий позицию Virtualization Program Manager в компании Microsoft, опубликовал несколько статей о том, как работает распределение ресурсов процессора в платформе виртуализации Microsoft Hyper-V R2 (кстати, не так давно вышел RTM-билд SP1 для Windows Server 2008 R2).
Приводим краткую выжимку. В настройках виртуальной машины на сервере Hyper-V вы можете увидеть вот такие опции:
Virtual machine reserve
Эта настройка определяет процентную долю процессорных ресурсов хост-сервера, которые должны быть гарантированы виртуальной машине. Если хост на момент запуска виртуальной машины не может гарантировать эти ресусры - виртуальная машина не запустится. То есть вы можете запустить 5 машин с Virtual machine reserve в 20%, а 6-я уже не запустится. При этом неважно, используют ли эти 5 машин какие-либо ресурсы, или они вовсе простаивают.
Однако, данная настройка имеет значение только когда ощущается нехватка процессорных ресурсов. Если 4 из этих 5 машин используют по 4% процента CPU хост-сервера, а пятая хочет 70% - она их получит, но до того момента, пока остальным не потребуются ресурсы процессора. То есть, настройка Virtual machine reserve гарантирует, что машина будет иметь в своем распоряжении ресурсов не меньше, чем заданный процент ресурсов CPU - в условиях борьбы за ресурсы процессора между машинами хоста.
По умолчанию в качестве Virtual machine reserve стоит настройка 0. Это означает, что вы можете запускать виртуальных машин столько, сколько позволяют физически доступные ресурсы хост-сервера Hyper-V.
Virtual machine limit
Эта настройка также задается в процентах. Она показывает какой максимально возможный процент процессорных ресурсов виртуальная машина может использовать от мощности своих виртуальных процессоров (в зависимости от их количества). Используется эта настройка в двух случаях - когда на хосте запущены тестовые виртуальные машины, которые могут при определенных условиях "съесть" все ресурсы, а также, когда приложение в виртуальной машине написано криво и может вызвать нагрузку на процессор, затормозив таким образом остальные машины.
Эта настройка активна всегда, что означает, что машина никогда не возьмет ресурсов больше чем Virtual machine limit, даже если свободных ресурсов очень много. Поэтому выставлять ее нужно в исключительных случаях, а для контроля ресурсов лучше использовать Virtual machine reserve. Кроме того, надо помнить, что Virtual machine limit применяется сразу к нескольким виртуальным CPU - поэтому, если приложение в виртуальной будет давать нагрузку только на один виртуальный процессор - он будет ограничен 50% доступных для него ресурсов, в то время как остальные будут простаивать.
CPU relative weight
Эта настройка позволяет выставить относительный вес виртуальных процессоров машины относительно других виртуальных машин. CPU relative weight - это просто число в диапазоне от 1 до 10000, которое определяет пропорциональный вес машины относительно других (по умолчанию выставлено 100 для всех). Если для одной из машин поставить значение 200 - то в случае нехватки процессорных ресурсов на хосте Hyper-V она получит в два раза больше ресурсов CPU, чем какая-либо из других. Обратите внимание - настройка начинает работать только в случае нехватки процессорных ресурсов на хосте и не раньше.
Смысл этой настройки - разделение виртуальных машин по категориям приоритета использования ресурсов в случае их нехватки (например, 300 - высокий приоритет, 200 - обычный, 100 - низкий). Так как это все относительные величины - имейте в виду, что здесь нет гарантий точного количества ресурсов CPU, получаемых машиной. И еще один момент - если в вашей виртуальной инфраструктуре Hyper-V работают несколько администраторов, то каждый из них может пользоваться своей классификацией весов. Например, у одного это 100, 200 и 300, а у другого - 500, 1000 и 2000. Если каждый из них для своего хоста установит эти значения, а потом за счет Live Migration какая-либо из машин динамически переместится на другой хост - распределение весов сильно изменится, что может повлиять на работу систем в условиях ограниченности ресурсов CPU хост-сервера.
В четвертой части заметок Бен рассматривает вопрос - почему эти значения задаются в процентах, а не в мегагерцах как у VMware. Ответ таков - 1 GHz обладает разной производительностью на разных поколениях CPU, а также хосты могут обладать разной мощностью процессоров, что делает предпочтительным использование относительных значений вместо абсолютных.
Как вы знаете, в механизме высокой доступности VMware High Availability (HA) есть такая настройка как Isolation Responce, которая определяет, какое событие следует выполнить хосту VMware ESX / ESXi в случае наступления события изоляции для него в кластере (когда он не получает сигналов доступности - Heartbeats - от других хост-серверов).
Leave powered on
Power off
Shutdown
Сделано это для того, чтобы вы могли выбрать наиболее вероятное событие в вашей инфраструктуре:
Если наиболее вероятно что хост ESX отвалится от общей сети, но сохранит коммуникацию с системой хранения, то лучше выставить Power off или Shutdown, чтобы он мог погасить виртуальную машину, а остальные хосты перезапустили бы его машину с общего хранилища после очистки локов на томе VMFS или NFS (вот кстати, что происходит при отваливании хранища).
Если вы думаете, что наиболее вероятно, что выйдет из строя сеть сигналов доступности (например, в ней нет избыточности), а сеть виртуальных машин будет функционировать правильно (там несколько адаптеров) - ставьте Leave powered on.
Но есть еще один момент. Как вам известно, VMware HA тесно интегрирована с технологией VMware Fault Tolerance (непрерывная доступность ВМ, даже в случае выхода физического сервера из строя). Суть интеграции такова - если хост с основной виртуальной машиной выходит из строя, то резервный хост выводит работающую резервную ВМ на себе "из тени" (она становится основной), а VMware HA презапускает копию этой машины на одном из оставшихся хостов, которая становится резервной.
Так вот настройка Isolation Responce не применяется к машинам, защищенным с помощью Fault Tolearance. То есть, если хост VMware ESX с такой машиной становится изолированным, при настройке Power off или Shutdown он такую машину не гасит, а всегда оставляет включенной.
Рекомендация - иметь network redundancy для сети heartbeats. Не должен хост себя чувствовать изолированным, если он весь не сломался.
Копировать руками машину каждый раз, когда нужно внедрить какое-то оборудование, или просто для сохранения данных, это безумно неудобно. Вот для этого и была придумана технология автоматизированного бэкапа, написанная энтузиастами на скриптах perl: ghettoVCB.
Часто разговаривая с заказчиками и пользователями платформ виртуализации от VMware, я вижу, что у многих из них весьма широко применяются снапшоты (snapshots), в том числе для целей "резервного копирования". Эти снапшоты живут долго, их файлы разрастаются и поростают плесенью. Потом инфраструктура начинает тормозить, а пользователи не знают почему. И как это не казалось бы странным - удаление всех снапшотов у всех виртуальных машин решает их проблемы, с которыми они уже свыклись.
Сегодня я вам расскажу, чтоб вы наконец запомнили: снапшоты это в целом плохо и лишь иногда хорошо. На эту страницу мы с вами будем отсылать наших клиентов и пользователей виртуальных машин, которыми могут оказаться люди, не участвующие в процессе администрирования VMware vSphere, но пользующиеся функционалом снапшотов (например, веб-разработчики).
Начнем с того, когда снапшоты могут помочь (я имею в виду, конечно, руками делаемые снапшоты, а не автоматические, которые делает, например, Veeam Backup). Снапшоты в VMware vSphere оказываются полезны в очень ограниченных условиях (например, для проверки корректности работы обновления приложения или патча операционной системы). То есть эта та точка сохранения состояния виртуальной машины, к которой можно будет вернуться через небольшой промежуток времени. Ни в коем случае нельзя рассматривать снапшоты как альтернативу резервному копированию основных производственных систем, в силу множества проблем, о которых пойдет речь ниже.
Что плохого в снапшотах виртуальных машин на VMware ESX:
1. Снапшоты неконтролируемо растут (блоками по 16 МБ). Помимо базового диска ВМ фиксированной емкости вы имеете еще один файл отличий виртуального диска, который растет как ему вздумается (предел роста одного снапшота - размер базового диска). Особенно быстро растут снапшоты для ВМ с приложениями с большим количеством транзакций (например, почтовый сервер или сервер СУБД). Со снапшотами вы не имеете контроля над заполненностью хранилищ.
2. Большое количество снапшотов (особенно цепочки, в которых может быть до 32 штук) вызывает тормоза виртуальной машины и хост-сервера ESX (в основном замедляется работа с хранилищем). Проверено на практике. Даже VMware пишет так: "An excessive number of snapshots in a chain or snapshots large in size may cause decreased virtual machine and host performance". В качестве примера можно привести тот факт, что при аллокации блоков снапшота происходит блокировка LUN (в этом режиме он доступен только одному хосту, остальные ждут). Когда снапшот делается - машина подвисает из-за сброса памяти на диск.
3. Снапшоты не поддерживают многие технологии VMware, созданные для автоматизации датацентров. К ним относятся VMware Fault Tolerance, Storage VMotion и другие. Когда одни машинки в чем-то участвуют, а другие не участвуют - это нехорошо в рамках концепции динамической инфраструктуры.
4. Снапшоты вызывают специфические проблемы при операциях с ВМ. Например, расширение диска виртуальной машины со снапшотом приводит к потере данных и непонятками, что дальше с такой машиной делать. Сто раз уже пользователи влипали (вот как вытянуть себя за волосы). Интересно также восстановить из снапшота машину с IP-адресом, который на данный момент уже используется в сети.
5. Со снапшотами бываютбаги, а бывает, что они просто "by design" тупят.
1. Контролируйте наличие снапшотов у виртуальных машин и их размеры, своевременно удаляйте их совместно с владельцами систем. Делать это можно, например, с помощью RVTools.
2. Не храните снапшоты больше 24-72 часов. Этого времени достаточно, чтобы оттестировать обновление ПО или патч ОС (ну и, конечно, сделать бэкап).
3. На сервере VMware vCenter можно настроить алармы на снапшоты виртуальных машин. Сделайте это. Дрючьте пользователей за необоснованные снапшоты.
4. Не позволяйте делать больше 2-3 снапшотов для виртуальной машины в принципе, если это делается в производственной среде. На своих выделенных для тестирования ресурсах (изолированных) пусть разработчики делают что хотят.
5. Если вы используете ПО для резервного копирования через снапшоты ВМ (например, Veeam Backup), помните, что бывает некоторые невидимые в vSphere Client снапшоты (Helpers) остаются на хранилище. Поглядывайте за машинами из командной строки.
Как вы знаете, у компании VMware есть несколько инициатив в сфере облачных вычислений - это семейство технологий vCloud, продукт vCloud Director для создания субоблаков и управления ими, надстройка vCloud Request Manager (портал самообслуживания пользователей облачных виртуальных машин + управление жизненным циклом ВМ) и ветка vCloud Express для создания облачной виртуальной инфраструктуры на площадках провайдеров, предоставляющих в аренду виртуальные машины. Сюда нужно присовокупить еще продукт VMware vCenter Chargeback, который обсчитывает все аспекты затрат на виртуальную инфраструктуру, и множество других продуктов семейства vCenter. Плюс вспомогательные продукты семейства vShield.
Теперь вот появилась новая инициатива - VMware vCloud Connector. По-сути, это механизм соединения облачных инфраструктрур на базе VMware vSphere (но не только).
На практике это будет означать вот что: VMware vCloud Connector - это будет абсолютно бесплатный плагин к VMware vCenter, с помощью которого пользователь своей частной виртуальной инфраструктуры может перемещать свои виртуальные машины в облако, т.е. к провайдеру, который дает виртуальную инфраструктуру в аренду. Происходит это, в том числе, с использованием VMware vCloud API.
При этом виртуальные машины по-прежнему остаются под контролем своего vCenter в vSphere Client:
Кроме того, в составе VMware vCloud Connector будет идти виртуальный модуль (Virtual Appliance), который вы импортируете в свою инфраструктуру VMware vSphere.
Поначалу VMware vCloud Connector, который выйдет уже в конце этого квартала будет поддерживать только двух провайдеров US Bluelock и European Colt, но потом эта инициатива дойдет и до нас.
Почему такая возможность будет полезна вам? Да потому, что у провайдеров облако, а у вас не облако. Облако - это не просто установленная vSphere, но и много чего еще. Например:
Контроль и мониторинг ресурсов
Классы сервиса для групп приложений и отдельных клиентов в целом (SLA) с ответственностью за простой
Контроль жизненного цикла виртуальных машин
Прозрачная система расчета стоимости ресурсов
Централизованное обеспечение безопасности на уровне датацентра
Фишка в том, что VMware vCloud Connector - это всего лишь начало большой инициативы, о которой станет известно чуть позже. Там будут и сторонние гипервизоры, и федерация гибридных облаков, и много чего еще. Не волнуйтесь - скоро обо всем расскажем. Напоследок картинка:
Итак, parent partition в грядущей Windows 8 (или как там ее еще назовут) будет выполнять не полноценную копию операционной системы, а ее мини-версию, которая сейчас идет под рабочим названием MinWin.
Эта ветка Windows, говорят, существует еще со времен Windows Vista и включает в себя ядро ОС, Hardware Abstraction Layer (HAL), комоненты работы с файловой системой и средства работы в сети.
Само собой, эта Windows меньше, чем Windows Server Core edition. Недавно Microsoft зарегистрировала патент на технологию Windows Direct Experience, которая будет позволять запускать некоторые приложения (например, Windows Media Center) в режиме "песочницы" (sandbox), т.е. по-сути в виртуальных машинах, как следует из картинки:
Родительским разделом по имеющейся информации будет рулить Hyper-V 3.0 (или как там его еще назовут), который, по-сути, будет играть роль клиентского гипервизора (который в данный момент есть только у Citrix - XenClient). Также можно будет грузить компьютер только в режиме одной из виртуальных машин. Кроме того, ходят слухи, что все это каким-то образом будет интегрировано с Microsoft App-V, средством виртуализации и доставки приложений конечным пользователям, а также механизмом MED-V.
Интересной возможностью будет "оффлайн" обновление операционных систем и приложений. Посколько ВМ это всего лишь набор файлов, то приложение внутри этой виртуальной машины можно запустить, обновить, перегрузить эту "машину" сколько угодно раз - и это в отрыве от основной операционной системы и других приложений. Замечательно.
Предлагают и вовсе фантастические вещи: так как гипервизор Hyper-V 3.0 может управлять не только ОС Windows, то компьютер, оснащенный Windows 8 (или как ее там) сможет выполнять и операционную систему Linux в режиме клиентского гипервизора, а пользователь, например, сможет запускать в этом линуксе свои приложения, которых (и такое бывает) нет в Windows. Это же относится и к приложениям, которые работают под устаревшими ОС XP или Vista.
Получается, что мы получим не совсем Windows а уже метаоперационную систему на домашних компьютерах. Это, по крайней мере, очень интересно. Ждем новых подробностей. Дополнительно можно почитать тут.
И да, поскольку эта информация не проверенная и не официальная, то никто ничего не гарантирует в окончательном релизе.
Таги: Microsoft, Windows 8, Update, Hyper-V, VMachines, App-V, MED-V
Как вы знаете, в мире виртуализации есть так называемые виртуальные модули (Virtual Appliances), которые позволяют распространять программное обеспечение в виртуальных машинах, готовых к развертыванию в инфраструктуре клиента. То есть, Virtual Appliance просто импортируется через клиент для управления платформой виртуализации (например, vSphere Client или XenClient), а само приложение работает в недрах этой виртуальной машины, предоставляя свои сервисы по сети, а управление через веб-фронтэнд.
Есть такая контора DMTF, которая занимается развитием стандартов в области управления ИТ-системами. Она, например, имеет свои спецификации по открытому стандарту распространениия виртуальных модулей OVF, который в будущем должны стать единым стандартом развертывания ПО в виртуальных машинах. В данной инициативе принимали участие компании Dell, HP, IBM, Microsoft, VMware и XenSource (еще до покупки компанией Citrix).
По своей сути стандарт OVF подразумевает кросс-платформенность, но на деле этого нет, так как он весьма скудно описывает сам образ виртуального диска (VMDK, VHD и пр.), уделяя большее внимание метаданным. Но так как каждая платформа виртуализации работает только со своим форматом виртуальных дисков, то есть некоторые проблемы с распространение данного "открытого" формата.
Виртуальный модуль в формате OVF представляет собой набор файлов, куда входят виртуальные диски (например, VMDK) и файл с расширением *.ovf, реализующий открытое описание файлов конфигурации виртуального модуля. Есть также подвид OVF - файл *.ova, который является TAR-архивом файлов OVF-пакета. То есть, ova-файлы идут по одному для каждого виртуального модуля, поэтому их проще распространять. С точки зрения размера и быстродействия OVA/OVF примерно одинаковы:
Когда вы делаете экспорт виртуальной машины из vSphere Client для создания виртуального модуля (Export OVF Template), вам как раз предлагают выбрать нужный формат OVF/OVA:
Так что вот - основная идея такова, что независимые разработчики ПО должны прежде всего ориентироваться на формат OVF / OVA при распространения своего ПО в виртуальных машинах. Но вот что непонятно - почему в VMware vCenter Converter Standalone 4.3 убрали поддержку OVF: "Support for OVF format is discontinued"?
В конце 2010 года фирма Intel сообщила о своем желании приобрести одного из ведущих поставщиков антивирусных решений — McAfee. На первый взгляд, — несуразное решение, но только на первый. Встраивание механизмов защиты от вирусов непосредственно в аппаратуру компьютера — это многообещающая идея и новая ступень в развитии антивирусных технологий.
Таги: VMachines, Hardware, Security, Intel, McAfee, Red Pill,
RSS
